home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Nov 89 / 0063-Re, to Limitations o-Nov89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.0 KB  |  52 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  BURBECK.S    to DAVIS.JIM    POTEL
  2.  
  3. Item forwarded  by  BURBECK.S    to BERNS1       EYES
  4.  
  5. Item forwarded  by  A33          to A34
  6.  
  7. Item    7062740                         8-Nov-89        17:33
  8.  
  9. From:   ARBOGAST                        Peat Marwick, Chris Arbogast,VCA
  10.  
  11. To:     BEL0076                         Hermes Systems SA
  12.  
  13. cc:     MACAPP.TECH$                    MacApp Technical
  14.  
  15. Sub:    Re, to Limitations of MacApp
  16.  
  17. BEL0076,
  18.  
  19.     We have also built such an application.  There are lots of things that 'get
  20. you' when the application becomes this large.
  21.  
  22.     It's been months since we could compile a qDebug version.  Just to many
  23. jump table entries for the linker.  Link is not particularly friendly about
  24. this.  Usually it just hangs or crashes.
  25.  
  26.     We've had to do all of our builds with -clean turned on since we now
  27. overflow the symbol table information that pascal keeps around otherwise.  This
  28. happens before it should because of bugs in the 3.0 and 3.1ß compilers.
  29.  
  30.     Turnaround time is horrendous, now made worse by -clean.  On a Mac IIci
  31. with a MPW partition > 2.5 Megs. It takes One hour and 15 minutes to do a full
  32. recompile with -autobuild.  Fastest turnaround for changes to a single
  33. implementation file run about 4 - 6 minutes depending on the file.
  34.  
  35.     The recently mentioned USES nightmare (bug) in Pascal has been hell.  In
  36. order to manage a project of this size it has to broken up into seperate units.
  37. Good luck.
  38.  
  39.     We had to resegment some of the resident segments in MapApp because the
  40. native sementation blows the CODE size limit of 32K when you actually use most
  41. of it. (ie it is not being dead stripped)  I can't recall exactly but I believe
  42. we changed the mapping of MAScroll from GRes to ARes in the Basic Definitions
  43. file to get around this one.
  44.  
  45.     As you can see, we've definitly run into some walls.  Still, I'm not sure
  46. if there exists another Object capable environment with a mature class library
  47. for the Mac that could handle this any better.
  48.  
  49.     Chris Arbogast
  50.     KPMG Peat, Marwick, Main, & Co.
  51.  
  52.